Greetings,

I would like my G-Code to be able to signal the following commands:

1. Spindle High Speed (Step and direction servo motor - Axis 5)
2. Spindle Low Speed (If a switch is on)
3. Spindle Off if (switch is off)
4. Axis 4 motion to position 1
5. Axis 4 motion to position 2
6. Axis 4 motion to position 3

Hi Scott,

Regarding fscanf in an infinite loop: A tight loop would be a bad idea.  Once every 30 seconds might be fine.  Maybe you could explain why you need to do this and what you are trying to do.  Also why using normal M-Code programs doesn't work for you.  I assume you are trying to get better performance?  I wouldn't think a simple M Code every 30 seconds would affect things measurably.  Although be aware that a call to fscanf requires a response from the Windows PC which on rare occasions may not respond for a second or so.

I don't understand 2 and 3.  Do you mean trigger the Spindle to be set to a low speed if an external input comes on?

Regarding 3 positions:  two bit encoding is probably a bad idea as changing more than one bit at a time can have a chance of invalid codes to be detected when they are both transitioning.   Virtual IO bits are cheap.  I'd use 3 normally all off.  To command a move to a position have the GCode set the appropriate bit.  Whenever the C Program detects a bit have it clear the bit and then command a move to that position.

Using the least number of Threads is advantageous.  The KFLOP DSP CPU Resource is passed around the active Threads in a round robin manner advancing to the next Thread every 90us.  The larger the number of active Threads, the longer the time between when each Thread gets to execute.  Imagine a circle of people with only one shovel.  Each person gets to use the shovel for 1minute then passes it on to the next person.   If one person needs to dig a big hole then the fewer in the circle will allow him to work faster.  So if an additional task of filling 3 cups is required it is better to add one new person responsible for filling the 3 cups rather than 3 new people, especially if you only care the cups get re-filled once per hour.     

 

Greetings,

I would like my G-Code to be able to signal the following commands:

1. Spindle High Speed (Step and direction servo motor - Axis 5)
2. Spindle Low Speed (If a switch is on)
3. Spindle Off if (switch is off)
4. Axis 4 motion to position 1
5. Axis 4 motion to position 2
6. Axis 4 motion to position 3

I am currently able to do all of these by launching a custom M-Code program. I am wanting to see if I can simplify things by making my M-Codes set bits, and my infinite loop in my INIT program would take care of the rest. Here are some problems I am facing.

1. Spindle High Speed - I am reading in a text file from the computer with this value. If I put the fscan into the infinite loop, would this cause system problems? Take up all of my bandwith on the USB? I really only need it to update every 30 seconds or so. Will fscan cause problems if there is coordinated motion going over the USB, or if an external button is sending a "DoPCInt" command or something? Any thoughts?
   
2. Spindle Low Speed / Off - I have tried to put an if statement into the infinite loop to enable / disable the axis 5 after checking the switch. Seems that if I do "EnableAxis" or "DisableAxis" it doesnt work. Would a jog command work better than enabling the axis?
3. Axis 4 Motion - Maybe I just set up some 2 bit logic? Position 1=00, Position 2=01, Position 3=11. My Mcode would simply set the two bits to the correct position? Could there be a better way than this?

In general, is it better to have one longer infinite loop statement in the INIT file rather than multiple threads running their own loops?

Thanks!

Scott

Hi Scott,

That helps.  I like optimization problems like this.  But a few more questions if possible.  I'm trying to understand the constraints that determines what can be done in parallel or ahead of time.  In general what varies from cycle to cycle?  A video might be helpful :)

btw it doesn't seem like there are any complex GCode patterns where USB bandwidth would be an issue.

How long does M102 usually hold for?

Could the S RPM (without M3 Spindle on) be sent before the M102 wait?

Could you explain more about M100.  What is "Cycle Data"?

What does the 10 lines of G Code do?  Does it need to wait for the Spindle to be up to speed?

 

Tom,

Perhaps I can explain a bit better. My machine has 3 parts:

1. 4 Axis Coordinated motion to position a small razor blade
2. Part loader - 1 Axis with pneumatic pickup head
3. Unloading chute - 1 Axis with pneumatic components

The cycle time for the whole process is 4-12 seconds. Depending on the part number, we run about 120,000 cycles each day. Cycle time is extremely important, we are doing multiple part changeovers one each machine, sometimes 2-3 per hour.

Our machine operators interface with a web based touch screen, they scan the bar code on the part number, make some adjustments and the HTML program saves the appropriate NC file locally. The CNC program goes like this:

• M102 - Holds Program until two conditions are met (part in spindle, loader Clear)
  
• M3 S RPM Variable- Starts Spindle
  
• M100 - "Execute PC" Starts a .BAT file for a Python program for Cycle data
  
• 10 lines of G-Code
• M09 - Moves Unloading chute to queue position
• 2 lines of  G-Code
• M08 - Unloading Chute In
• M5 S 750 - Slows spindle or stops it based on a selector switch
• M101 - Another "Execute PC" .BAT file
• M30 - Checks a selector switch, if in "Auto" will restart the cycle DOPC(PC_COMM_EXECUTE)

The loader is running in a different thread to pickup and queue parts to be ready when the cycle restarts. 

With all of these MCodes I am loosing almost 2 seconds in wait time. Also my M9 is inside the G-Code, it causes a pause between .1 to .4 seconds in the CNC program. Seems like if there is a longer pause it causes a following error. 

I think it may help to not send the spindle RPM through the G-Code, but have my INIT file read it in from a text file. That way the MCode would be just setting an IO bit and wouldnt pause the G-Code as long. I was thinking the same thing for the M9 and M9 chute positions. They just set a bit and the INIT infinite loop will move them to the correct positions. Does this sound reasonable? Is there a better way?

The loader moves to different positions for each part number - it reads a text file after it completes loading a part (4-12 seconds). Could I have it also read the spindle speed file and save the value as a global variable that is accessible to the INIT loop file? Will reading these two files take a lot of system resources from coordinated motion that could be happening at the same time? Maybe mess up the cycle restart in the M30 G-Code?

Thanks,

Scott

trimprogramtest-13743.txt

SetGCodeVarToZero-13744.c
ConditionalHalt-13744.ngc

Hi Scott,

I think I'm starting to understand.

I think the approach of embedded IO commands to trigger operations is probably the way to go.

It seems like all the data for each cycle (Spindle Speeds and the data file for load/unload positions?) is the same for each cycle.  If so, I'd suggest downloading that to KFLOP only once before the first cycle.  After that the "triggered operations" can just access that instantaneously.

I've attached a method that does an infinite loop of GCode that halts when a GCode Variable is cleared and an example of how to clear a GCode Variable from KFLOP.   I think method this might help you in two ways.  #1 it allows doing special stuff before the first cycle.  #2 it should be faster as the GCode doesn't need to Halt and Restart each cycle which involves a Motion buffer flush and refill etc...

Could you elaborate further on the M100/Batch File/Python/Time Stamp?  Is that really necessary and what is the purpose?  As that will basically cause a GCode Halt until Windows processes the Batch file.  It might be possible to trigger that from KFLOP so it happens in the background in parallel with the Cycle Sequence.

Regards

TK

 

Tom,

M102 can hold for different amounts of time- The goal is zero depending on if the cutting cycle time was faster than the part pickup time. Pickup time varies depending on part availability from the bowl feeder. Normally the part is ready to go in immediately. Reading in the spindle speed before M102 would only help if the loader wasnt ready to load immediately. Though maybe it could be doing that as the pick head is going in and out?

Spindle is up to speed before the blade gets close. M9 happens at the same time the cut head is exiting the cutting area. Idea is to have the chute in a close but safe position so it can quickly go in after the cutter is clear.

M100 saves a time stamp to the network - Cycle Start, and Cycle Complete. A Python program which is started by a .BAT file.

Most variation comes from the part loader, sometimes it has a part immediately, other times it waits a few seconds. 

Loader Positions (running independently in a thread)

1. Wait in a out of the way position to allow parts to enter the loading area
   
2. Once a part arrives - Move to the location get part (changes on every part - value read in through text file) 
   
3. Move to a close position to the cutting zone until it is clear (queue position to save time)
   
4. Move into the cutting zone (locks a bit to prevent cutter / unloader from entering)
   

CNC Cut Head (G-Code Driven)

1. Stay out of the way if there is no part
   
2. Cutting zone

Unloading Chute (Positions triggered by M-Codes)

1. Close to cutting zone - triggers as the cutting head is retracted
2. Cutting Zone
3. Down over tote

I hope that this is all clear. Does it appear that I am using a good approach to this problem? I am open to suggestions to pull out any time that I can.

Thanks,

Scott

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

Hi Scott,

That helps.  I like optimization problems like this.  But a few more questions if possible.  I'm trying to understand the constraints that determines what can be done in parallel or ahead of time.  In general what varies from cycle to cycle?  A video might be helpful :)

btw it doesn't seem like there are any complex GCode patterns where USB bandwidth would be an issue.

How long does M102 usually hold for?

Could the S RPM (without M3 Spindle on) be sent before the M102 wait?

Could you explain more about M100.  What is "Cycle Data"?

What does the 10 lines of G Code do?  Does it need to wait for the Spindle to be up to speed?

M09 - what limits when that can start moving? What is Queue Position?

What does the 2 lines of G Code do?  Push something into the Chute?

M5 Spindle Slow/Stop is there a need to wait for it to Slow/Stop

What is M101 for?

I don't understand the M9 pause/following error issue.

Regards
TK

On 9/15/2016 9:23 AM, cnc_machines@... [DynoMotion] wrote:

 

Tom,

Perhaps I can explain a bit better. My machine has 3 parts:

1. 4 Axis Coordinated motion to position a small razor blade
2. Part loader - 1 Axis with pneumatic pickup head
3. Unloading chute - 1 Axis with pneumatic components

The cycle time for the whole process is 4-12 seconds. Depending on the part number, we run about 120,000 cycles each day. Cycle time is extremely important, we are doing multiple part changeovers one each machine, sometimes 2-3 per hour.

Our machine operators interface with a web based touch screen, they scan the bar code on the part number, make some adjustments and the HTML program saves the appropriate NC file locally. The CNC program goes like this:

• M102 - Holds Program until two conditions are met (part in spindle, loader Clear)
  
• M3 S RPM Variable- Starts Spindle
  
• M100 - "Execute PC" Starts a .BAT file for a Python program for Cycle data
  
• 10 lines of G-Code
• M09 - Moves Unloading chute to queue position
• 2 lines of  G-Code
• M08 - Unloading Chute In
• M5 S 750 - Slows spindle or stops it based on a selector switch
• M101 - Another "Execute PC" .BAT file
• M30 - Checks a selector switch, if in "Auto" will restart the cycle DOPC(PC_COMM_EXECUTE)

The loader is running in a different thread to pickup and queue parts to be ready when the cycle restarts. 

With all of these MCodes I am loosing almost 2 seconds in wait time. Also my M9 is inside the G-Code, it causes a pause between .1 to .4 seconds in the CNC program. Seems like if there is a longer pause it causes a following error. 

I think it may help to not send the spindle RPM through the G-Code, but have my INIT file read it in from a text file. That way the MCode would be just setting an IO bit and wouldnt pause the G-Code as long. I was thinking the same thing for the M9 and M9 chute positions. They just set a bit and the INIT infinite loop will move them to the correct positions. Does this sound reasonable? Is there a better way?

The loader moves to different positions for each part number - it reads a text file after it completes loading a part (4-12 seconds). Could I have it also read the spindle speed file and save the value as a global variable that is accessible to the INIT loop file? Will reading these two files take a lot of system resources from coordinated motion that could be happening at the same time? Maybe mess up the cycle restart in the M30 G-Code?

Thanks,

Scott

float speed = *(float *)&persist.UserData[0];  // value stored is actually a float)

During part change over the loader pickup location changes and the spindle speed changes (unloader always the same). I am currently rereading the text file on each cycle. If I pull this out of an MCode, how would the infinite loop know a new cycle has started, and it needs to update the files? Maybe I could use the MCode to set a bit, the loop would check the bit read the txt file and then clear the bit out?

The M100 batch file uploads data to a SQL server (the computer ID, Operator Badge Number, Time stamp for when Cycle start/end). We run reports from this data. The .bat file speeds things up, the python program takes a few seconds to execute so this was a work around. Are you thinking the KFlop could make the "Execute PC" command based off of a toggled bit from KMotion?

Scott

Hi Scott,

Regarding SetUserDataDouble and global persist variables:  "double" is a 64 bit floating point value (with ~17 digits of precision) and requires a pair of global persist variables.  Since GCode Variables are doubles they are transferred to/from KFLOP as doubles.  For simplicity Spindle speed is transferred as a 32-bit "float" as 6 digits of precision should be more than sufficient for a speed setting.  See:

http://www.dynomotion.com/wiki/index.php?title=KFLOP_C_Programs#Global_Persist_Variables

 

Tom,

Thanks again, I reviewed the code and think I understand how it works. Just a few questions. 

Is "SetUserDataDouble" one of the global variables that is available to all threads? How many of these variables are available for use? Basically the same thing as reading spindle speed from an M Code?

float speed = *(float *)&persist.UserData[0];  // value stored is actually a float)

During part change over the loader pickup location changes and the spindle speed changes (unloader always the same). I am currently rereading the text file on each cycle. If I pull this out of an MCode, how would the infinite loop know a new cycle has started, and it needs to update the files? Maybe I could use the MCode to set a bit, the loop would check the bit read the txt file and then clear the bit out?

The M100 batch file uploads data to a SQL server (the computer ID, Operator Badge Number, Time stamp for when Cycle start/end). We run reports Hthis data. The .bat file speeds things up, the python program takes a few seconds to execute so this was a work around. Are you thinking the KFlop could make the "Execute PC" command based off of a toggled bit from KMotion?

Scott

On 2016-09-21 14:23, cnc_machines@... [DynoMotion] wrote:
> Tom,
>
> Hitting a bit of a roadblock in putting move positions into my
> infinite loop. My INIT program has a loop that needs to execute very
> fast - checking position of buttons, etc. My MCode is setting a bit,
> that will cause my infinite loop to move to the required location.
> Normally I make code that looks like this:
>
> if(ReadBit(1058)) //Read MCode Bit
> {
>
> Move(4, -38500);
> while(!CheckDone(4));
> }
>
> Problem is that I dont want to pause my main loop for the amount of
> time it takes the axis to get to position. If I leave out the while
> statement the axis doesnt move at all. Is there another way to do this
> without locking up the whole loop?
>
> Thanks,
>
> Scott